see also:
SXKey updates:
SN_ThisNode = 5 ;Node of this module ERROR p2w '----------------- Node set to ' SN_ThisNode ' -----------------'
The IDE on the older versions of this product wasn't great. See Read, Program and Debug the SXKey using a QBASIC-program (QBL99V3.BAS) and http://sourceforge.net/projects/gsxprog/ ( http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/gsxprog/?cvsroot=gsxprog ) for efforts to replace it.
Having problems in Windows XP with the serial port? Peter Montgomery says:
Go to the hardware manager and open the settings for the serial ports. For the port that's attached to the SX-Key, check the FIFO settings. Most likely it's something like 14/16 bytes. Set the values down to something low like 3/4 bytes. I have found this often cures a number of SX-Key anomalies such as random disconnects. You might even want to experiment with turning the FIFO off. I know the FIFO is a nice thing to "take the strain" off the CPU, but when everyone is running 800 MHz and up CPUs, I find the CPI can handle the burden.
Stephen Holland says:
The device directives OSCLP1, OSCLP2, OSCXT1, OSCXT2, OSCHS1, OSCHS2 and OSCHS3 correspond to the following settings shown in the SX datasheet (taken from the SX28 here, but SX52 is the same):FOSC2: FOSC0 External oscillator configuration (valid when IRC = 1): 000b = LP1 - low power crystal (32KHz) 001b = LP2 - low power crystal/resonator (32 KHz to 1 MHz) 010b = XT1 - normal crystal/resonator (32 KHz to 10 MHz) 011b = XT2 - normal crystal/resonator (1MHz to 24 MHz) 100b = HS1 - high speed crystal/resonator (1MHz to 50 MHz) 101b = HS2 - high speed crystal/resonator (1 MHz to 50 MHz) 110b = HS3 - high speed crystal/resonator (1 MHz to 50 MHz)Even when using an external 50MHz crystal oscillator, you will still need some gain, so I suggest using OSCHS1 or OSCHS2. The directive 'INPUT' is the same OSCLP1, and after significant testing, is not suggested, even for external crystal oscillators. That is why the current revs of SX-Key software do not provide this selection in the device configuration window, even though the directive itself may not give an error.
SX-Key software for SX28 rev 1.08+ and SX52 rev 1.16+ have support for these directives.
There is no difference between Rev E and Rev F of the sxkey other than the cable.
William K Borsum of Dascor says:
The SX-Key must have five volts input.There is a DC-DC on the board but they couldn't/wouldn't tell me specifically what it was for.
The outputs from the SX-Key (OSC1, 2) must NOT be clamped to anything. Apparently there is a higher voltage required on these pins to tell the target chip that it is in SX-Key/debug/program mode.
The higher voltage on OSC1 and OSC2 will NOT appear on any other pins of the target chip.
The five volt supply on the SX-key can be different from the target chip--i.e. the SXkey can run from a five volt supply (single 7805, caps and wall wart= SX-Key-Ring) while the target system runs from its own supply. Only common pins are GND, OSC1, OSC2. The power rails are NOT connected if a different voltage.
To replace a PIC 16x5x with an SX18 or 28, just get the hex file from MPLAB, etc... and open it in the SX-Key software under Run / Device / Load Hex. Don't open the hex file with File / Open; use Run / Device / Load Hex. You can either rename the hex file to .sxh or enter *.hex in the File Name control and hit enter to see the file. Ensure that the options are set correctly (you may have to try several different Oscillator Crystal options to find the one that works best for your circuit) then press Program then Verify. If you turn on the Turbo mode, your code will run approximatly 4 times faster with the same clock, but timing sensitive items (bit banged serial, IIC etc...) may be affected. The Options for Stack and ADD/SUB with C should not be used.
.sxh file format:
:BBAAAARRLLMMLLMMLLMM......LLMMCC
BB # data bytes
AAAA load offset (address x 2 as msb:lsb)
RR record type, 00=dat,01=eof
LL lsb code word
MM msb code word
CC checksum
Don Wade [WadeD at ncc.edu] explains how to use SXSim with the SXKey's assembler
Here's the instructions I give my students when we use SX Sim:In order to use the simulator program you need to produce a "list" file of your program. You can do this with SX Key as follows. First write your program and assemble it (with no errors). Save it under whatever name you wish using the "FILE-Save As" function if it does not already have the proper name. After you have written your program, In the FILE menu click on "Toggle List On" --this will show the list file with both code and mnemonics. Then click FILE - SAVE which will save a list file under the same name but with the extension ".lst" instead of ".src."
Note: If you click on "Save As' and try to rename the file, SXKey will usually add on the ".SRC" extension so the file will be saved as XXXX.LST.SRC (where XXXX is the name you gave your file). This file will not work in simulate and you need to change its extension. Open up the folder the files are in. You should see the XXXX.LST.SRC file. Click (only once) on it to highlight it and then press F2 in order to edit the file name. Use the right arrow key to move to the end of the name and then backspace over the extra extension so it now is XXXX.LST only. [Or use any other method you find easier to change the extension to ".LST"]
JP Harrison offers some advice for troubleshooting problems with the SXKey:
Make sure you have built the simplest circuit possible. Use new chips, test all connections.Is your power supply stable?
Breadboards don't always make good contacts, especially if they have been used quite a few times. If necessary, wire-wrap a test circuit.
Keep a known (simple) test circuit on your bench. Use this for a sanity check every once in a while.
Check your serial port to see that it is working. You can use an old external modem - hook it up, and install it (on Windows) - you can then do a test on it - the lights should blink. If they do, and Windows can identify the modem, your COM port is almost certainly working. Use the SAME cable to connect to the Key. Of course, you can hook up your serial port to another computer, and use Hyperteminal to communicate. BUT: don't forget you have to cross the receive and transmit lines, so you can't use this cable to connect to the Key.
Write a little 3 line program to see if the chip can be erased and programmed.
DO NOT use the sleep command; if you do, you'll have to reset the chip before re-programming, or you'll get the message "Chip connection failed".
I found that I could reverse the Key connections, and it would not blow up the Key - I don't recommend it, but it didn't seem to hurt anything. I also reversed the SX28, and the Key was still fine - it also didn't (seem to) hurt the SX28, but again I don't recommend doing this.
It seems that the Key is pretty robust. The first thing you should suspect (if you can't program the chip) is your circuit (or the chip itself).
The tech people at Parallax were very helpful.
Guenther Daubach says:
Today, I made an intersting experience with the SX-Key.I was testing a little SX application, handling a UART VP sending out serial data to a PC COM port. As I had only conncted one serial cable to the PC, and did not want to spend too much time, installing another one (you know - creeping on the floor, locating the COM port, trying to figure out where the other end of the cable is located...) in order to use different COM ports, one for driving the SX-Key, and one for capturing the SX serial output with HyperTerminal, I had to go with just one COM port for both.
<SNIP>
Now, after programming the SX with SX-Key, it came to my mind that the SX-Key can also act as clock device. So, with the serial cable still connected to the SX-Key, I selected "Run - Clock", set the clock to 50 MHz, clicked the "Reset" and finally the "Ok" button to close the Clock window again.
Leaving the power on, I then unplugged the serial connector from the SX-Key, just to notice that the SX continued execution of the program, as some status LEDs continued blinking as expected. I then plugged the serial cable into the SXes serial port. After launching HyperTerminal, I could nicely see the serial data sent from the SX with the SX-Key acting as clock source.
Looks as if the SX-Key simply continues generating the clock signal defined by "Run - Clock", even if the serial cable is no longer connected to it.
Well, this has one drawback: As soon as you un-/re-power the system (or even a "glitch" on the power supply) brings the SX-Key into idle mode, and it stops clock generation. I did not test if the SX-Key also stops clock generation when the SX MCLR* pin is pulled low for a reset.
Nevertheless, this saved me some work during the test phase today, as there was no need to plug/unplug the resonator/SX-Key all the time.
Using the SXBLITZ-protocol with a SXKEY instead of a SXBLITZ
Read, Program and Debug the SXKey using a QBASIC-program (QBL99V3.BAS)
See also:
| file: /Techref/parallax/sxkey.htm, 20KB, , updated: 2013/7/30 07:04, local time: 2024/12/26 05:29,
3.139.86.74:LOG IN
|
| ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://massmind.org/Techref/parallax/sxkey.htm"> SX-Key</A> |
| Did you find what you needed? |
Welcome to massmind.org! |
Welcome to massmind.org! |
.